Embedded processors are ubiquitous: they form a core component of a vast range of everyday items (cars, aircraft, medical equipment, factory systems, mobile phones, DVD players, music players, microwave ovens, toys etc). In some cases several embedded processors may be employed, each for a specific function. For example, a typical modern car may contain around fifty embedded processors.
In applications where predicable behaviour is an important consideration—such as in automotive systems, aerospace systems, medical systems, industrial systems, and in many brown and white goods—it is vital that a reliable system is used and that it operates in a highly predictable manner. This is important for safety considerations but also because a reliable device is likely to incur reduced maintenance and/or repair costs (and resulting inconvenience to the user) during its operational life. Thus, it is important that such systems are sufficiently robust and that faults are quickly and easily detected so that appropriate action can be taken.
A time-triggered (TT) embedded system is a real-time system that executes a set of periodic tasks. Various forms of TT architecture have been suggested, ranging from the simplest form of “cyclic executive” with co-operative task scheduling through to rate-monotonic architectures which employ pre-emption.
Of particular interest are TT systems which employ co-operative task scheduling. These systems are also referred to as “time-driven cyclic executive”. Embedded systems which employ time-triggered co-operative (TTC) scheduling can have highly predictable patterns of behaviour, including very low levels of task jitter. When coupled with the fact that TTC implementations can have very low resource requirements, this architecture is an appropriate choice for cost-sensitive/safety-related applications, including automotive control.
Unfortunately, the behaviour of a TTC system may become unpredictable in situations where one or more tasks exceed their predicted “worst case” execution time (WCET). This situation is known as a task overrun. In hard real-time systems, task overrun may result in fatal consequences both for the system employed and, possibly, the user. Thus, a system-recovery mechanism is required and must be triggered immediately in response to such temporal constraint violations. In order to achieve this, it is necessary to continuously monitor the temporal behaviour of the system.
Over the last decades, much research has been focused on monitoring the run-time behaviour of real-time systems. The approaches taken can be classified into three categories:                Hardware-based monitoring approach        Software-based monitoring approach        Hybrid monitoring approach.        
These three approaches each have their pros and cons as discussed below.
Hardware-based monitoring involves non-invasive observation of the target system but is generally expensive and complicated. Additional hardware is required for the monitoring system, which is separate from the target system. The monitoring system generally comprises a complex architecture which connects to the target system and snoops for signals from its buses, memory system and input/output channels. The monitoring system then uses this information to imitate the target system and thereby discover its state. However, this approach requires sophisticated hardware, specifically tailored towards the target system. Moreover, it is difficult to measure signals from some buses or memory ports, due to the miniaturisation and integration of components in modern microcontrollers. Additionally, microcontrollers have a limited number of pins which may make the above approach infeasible.
Software-based monitoring, on the other hand, is cheap, simple and flexible. Instrumentation codes, also known as software sensors, are inserted at the points of interest in the software program of the target system. The software sensors are designed to record the status of the target system at those points of interest. However, this arrangement will produce some degree of interference with the run-time behaviour of the target system since the software sensors not only share resources with the target system but also inevitably increase the system's computational complexity. Many different techniques have been developed in an attempt to minimise the impact of this so-called ‘Probe Effect’ on the behaviour of the target system. One approach has been to build the monitoring system as a permanent part of the target system. This avoids having to remove the software probes with consequent distortion of the system's behaviour. Another approach suggests storing data values only if they cannot be reconstructed. In addition, it is suggested to use in-line software sensors instead of sensors that are called as functions. These two techniques can optimise the spatial and temporal aspects of the software monitoring approach. However, the probe effect of software monitoring cannot be completely eliminated simply because of its invasive nature.
The hybrid monitoring approach uses a combination of software and hardware monitoring and can alleviate some of the shortcomings of both approaches. In this approach, a software monitoring system captures events of interest in the target system and passes these to an external dedicated hardware device for further analysis. Consequently, this approach can minimise the probe effect caused by the software monitoring approach and can reduce the need for hardware connections to the target system. However, a specifically tailored hardware platform is still required with its attendant costs.
It is therefore an object of the present invention to provide a solution that ameliorates some or all of the aforementioned problems.